Method and system for processing transactions

ABSTRACT

A system and method are provided for processing transactions between at least one buying company and at least one selling company using a central datastore accessible to users from the buying company and selling company. Purchase order and invoice data are obtained and compared to identify a matched record having purchase order data and corresponding invoice data. A collaborative data set in the central datastore is created, based in part on the matched record and storing in the datastore detailed settlement data regarding settlement of the matched record of purchase order data and corresponding invoice data. A complete settlement transaction history is stored by providing for storage of additional settlement data in the central datastore, wherein credit memos, debit memos regarding the invoice, the purchase order of the matched record, and/or other documents related to the transaction are stored as part of the collaborative data set.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of priority to co-pendingU.S. Provisional Application Ser. No. 60/533,816 (Attorney Docket No.40877-1011) filed Dec. 30, 2003. This application is incorporated hereinby reference for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The technology described herein relates to processing businesstransactions, and, more particularly, to a method and system forproviding a single transaction point to process business transactionsbetween multiple trading partners.

2. Description of Related Art

When one company, a purchaser, desires to buy products from anothercompany, a supplier, an order is traditionally transmitted by the buyingcompany to the selling company via a purchase order. The purchase ordermay be for a single product or for more than one product. If more thanone product has been ordered, generally the purchase order will have aline item entry for each separate product. Often, a particularindividual associated with the buying company, typically designated a“buyer,” is responsible for each particular purchase order. A companymay have one or more such buyers.

The selling company then fills the order and sends the product(s) to thebuying company. The buying company generally notes the quantity ofproduct received on the purchase order, creating a receipt document.After the selling company has shipped the product(s), to the buyingcompany, the selling company generates and sends to the buying companyan invoice for payment for the product(s). Usually, the invoice willhave line item entries corresponding to those line item entries on thepurchase order and receipt document. Sometimes the invoice will haveline item entries corresponding to the line items on more than onepurchase order or receipt document. This invoice corresponds to areceivable asset of the selling company associated with the amount duefrom the buying company.

The selling companies may also sell the receivable associated with theinvoice to a third party, such as a bank or other receivables factoringparty, based on a discount from the receivable amount. This allows theselling company to receive the cash before the invoice is paid to bettermanage the cash flow. This also shifts the risk to the third party thatthe buying company will timely pay the invoice and will have no disputeswith the invoice information. This is known as factoring.

The current infrastructure in both traditional and internetbusiness-to-business transactions is highly fragmented with buyingcompanies and selling companies each dealing with hundreds or thousandsof parties, purchase orders, invoices, and receipt documents. A sellingcompany's billing data is a component of a buying company's accountspayable data. A buying company's remittance data is a component of aselling company's accounts receivable data. Further, a company may be abuying company for some products and a selling company for otherproducts.

For each buying company, there are many selling companies with which itis a trading partner. For each selling company, there are many buyingcompanies with which it is a trading partner. The buying companies andthe selling companies must each track their accounts payable andaccounts receivable information for each of the companies with whichthey do business. This can be illustrated as in FIG. 1, representing thetraditional interactions between businesses.

Thousands of companies each perform billing, invoice matching, andreconciliation activities independently and redundantly, despite thefact that they are all using the same source data, namely, the data fromthe purchase orders and corresponding invoices and receipt documents.The results of these activities are then shared between these companiesvia remittances, short pays, claims, etc. This business process cancreate unnecessary administrative confusion and expense.

Electronic billing, remittance, payment, and tracking technologies havegenerated limited savings because they have left the reconciliationenvironment within each individual company. Also, web-based billing andpayment solutions have achieved some success in moving informationbetween companies, but have required companies to maintain their owninternal accounts payable and accounts receivable functions which mayrequire a significant commitment of resources.

There are existing systems that coordinate customer billings andreceipts for a single selling company. However, such systems generallydoes not allow for the buying companies that are customers of thatselling company to access the financial information that is related tothe buying company's account. Likewise, such systems generally do notcoordinate the supplier billings and receipts for the buying company forsuppliers other than that selling company.

SUMMARY OF THE INVENTION

Accordingly, one object of the present invention is to provide improvedsystems and methods for invoice and purchase order reconciliation.

Another object of the present invention is to improve accuracy oftransaction settlement post-audits.

Another object of the present invention is to provide devices andmethods for enabling both the buyer and seller to more quickly settletransactions and reduce problems that may typically be caught in a postaudit.

Another object of the present invention is to provide devices andmethods to allow for transaction insight into the other trading partiesbusiness process, efficiencies, limitations, successes, etc thuscreating a more accurate view of both parties efforts in the financialand physical supply chain.

Yet another object of the present invention is to capture and linktogether in the system, all documents, memos, images, files, notes andcorrespondence related to the financial settlement of the transaction.

Still a further object of the present invention is to provide methods totrack and capture not only the original payment decision and/ordeduction but also all dispute requests, supporting documentation andsubsequent credits & debits until both parties are satisfied with thefinal settlement or recognize that any additional efforts will notaffect the outcome. This information as it is brought into the system isthen shared between both parties for a single source of data for thetransaction.

At least some of these objects are achieved by some embodiments of thepresent invention.

In one embodiment of the present invention, a method is provided forprocessing transactions between at least one buying company and at leastone selling company which results in the creation of a new collaborativedata set. The method comprises of providing a central datastoreaccessible to users from the buying company and users from the sellingcompany. Purchase order and invoice data are obtained and compared via acomputer, to identify a matched record having purchase order data andcorresponding invoice data. A collaborative data set in the centraldatastore is created, based in part on the matched record and storing inthe datastore detailed settlement data regarding settlement of thematched record of purchase order data and corresponding invoice data.The method stores a complete settlement transaction history by providingfor storage of additional settlement data in the central datastore,wherein credit memos, debit memos regarding the invoice, the purchaseorder of the matched record, and/or other documents related to thetransaction are stored as part of the collaborative data set.

In one embodiment of the present invention, a method is provided forprocessing transactions between at least one buying company and at leastone selling company which results in the creation of a new collaborativedata set. The method comprises providing a central datastore accessibleto users from the buying company and users from the selling company;obtaining via a computer network purchase order data having at least oneentry, the purchase order data including purchase order headerinformation and purchase order detail information; obtaining via acomputer network invoice data having at least one entry, the invoicedata including invoice header information and invoice detailinformation; comparing via a computer, selected purchase order data andcorresponding selected invoice data to identify a matched record havingpurchase order data and corresponding invoice data; creating acollaborative data set in the central datastore based in part on thematched record and storing in the datastore detailed settlement dataregarding settlement of the matched record of purchase order data andcorresponding invoice data; providing for storage of additionalsettlement data in the central datastore, wherein credit memos, debitmemos regarding the invoice and/or the purchase order of the matchedrecord are stored as part of the collaborative data set; if users fromthe buying company and/or selling company dispute settlement of thetransaction, then: 1) providing for storage of settlement dispute datafrom the selling company which is stored as part of the collaborativedata set; 2) providing for storage of supporting images anddocumentation from the selling company which are stored as part of thecollaborative data set; 3) providing for storage of settlement disputedata from the buying company which is stored as part of thecollaborative data set; 4) providing for storage of supporting imagesand documentation from the buying company which is stored as part of thecollaborative data set. The method may further involve reconciling thetransaction using the matched record and settlement dispute data storedin the datastore.

The method may also include a transaction that is reconciled using onlydata and documents captured and stored in the datastore as part of thecollaborative data set. Users from the buying company and sellingcompany may view, reconcile, adjudicate and report on all financialtransactions between the trading partners. Documents, memos, images,files, notes and correspondence related to the financial settlement of atransaction may be captured and linked together in the database. Thedatabase may include original payment decision and/or deduction but alsoall dispute requests, supporting documentation and subsequent credits &debits entered until both parties are satisfied with the finalsettlement. Information brought into the database may then be sharedbetween both parties for a single source of data for the transaction.All of the documents related to the transaction may be stored at acentral datastore to create a more accurate view of both parties effortsin the financial and physical supply chain. Of course, this centraldatastore may also be viewed as being a server which may be part of aserver farm or distributed storage network. However, the users frombuyers and sellers would come to this “single” platform to do theirsettlement transactions, even if on the backend, some embodiments mayhave the servers with the datastore in a distributed architecture.

Embodiment of the present invention may allow the at least one buyingcompany and the at least one selling company access to selected data inthe database comprises providing a web page accessible by the buyingcompany and a web page accessible by the selling company via a globalcomputer network. The purchase order header information may comprise ofa purchase order number, a client identification, a vendoridentification, and a purchase order date. The purchase order detailinformation may comprise of the purchase order header information, aquantity ordered for each purchase order entry, an item identificationfor each purchase order entry, a unit price for each purchase orderentry, and a charge code for each purchase order entry. The invoiceheader information may comprise of an invoice number, a clientidentification, a vendor identification, and an invoice date. Theinvoice detail information may comprise of the invoice headerinformation; a quantity shipped for each invoice entry; an itemidentification for each invoice entry; and an extended price for eachinvoice entry. In some embodiments of the invention, the step ofobtaining purchase order data comprises obtaining the purchase orderdata in electronic format. The step of obtaining purchase order data mayfurther comprise of obtaining the purchase order data via a globalcomputer network.

In some embodiments, the step of obtaining invoice data comprisesobtaining the invoice data in electronic format. The step of obtaininginvoice data may further comprises obtaining the invoice data via aglobal computer network. The step of obtaining purchase order data maycomprise of obtaining the purchase order data in paper format. Themethod may further comprise of the step of converting the purchase orderdata to electronic format. The step of obtaining invoice data compriseof obtaining the invoice data in paper format. The method may furthercomprise of the step of converting the invoice data to electronicformat. The steps may be conducted by a party other than the buyingcompany or the selling company. The method may comprise of the step ofautomatically comparing selected purchase order data and correspondingselected invoice data comprises performing an automated comparison usinga computer. The method may comprise of using a single platform providedfor handling all transaction for trade settlement.

In another possible configuration of the present invention, a method isprovided for tracking transaction settlement between at least one buyingcompany and at least one selling company. The method comprises providinga central datastore accessible to users from the buying company andusers from the selling company; obtaining via a computer networkpurchase order data having at least one entry, the purchase order dataincluding purchase order header information and purchase order detailinformation; obtaining via a computer network invoice data having atleast one entry, the invoice data including invoice header informationand invoice detail information; comparing via a computer selectedpurchase order data and corresponding selected invoice data to identifya matched record having purchase order data and corresponding invoicedata; creating a collaborative data set in the central datastore basedin part on the matched record and any subsequent settlement history;capturing post-match, settlement history by storing all additionalsettlement data to be used to as part of the same collaborative data setin the central datastore, wherein at least one of the following isstored: credit memos, debit memos regarding the invoice and/or thepurchase order of the matched record, settlement dispute data from theselling company, supporting images and documentation from the sellingcompany, settlement dispute data from the buying company, supportingimages and documentation from the buying company. In the method, usersfrom the buying company and users from the selling company may accessthe collaborative data set to reconcile the transaction using thematched record settlement transaction history and supportingdocumentation stored in the datastore.

In some embodiments, the transaction is reconciled using only data anddocuments captured and stored in the datastore as part of thecollaborative data set. Users from the buying company may viewadditional settlement data and documents added into the collaborativedata set by the selling company and vice versa. Additionally, users fromthe buying company may review additional settlement data added by usersfrom the selling company; and users from the selling company reviewingadditional settlement data added by users from the buying company. Thisis an iterative process and the reviewing steps may be repeated betweenthe buying company and selling company until a final settlement isreached or agreed upon.

In another embodiment of the present invention, an electronictransaction processing system including a computer network, a processingunit, and at least one data storage unit, is provided for performingsteps comprising: providing a central datastore accessible to users froma buying company and users from a selling company; obtaining via thecomputer network purchase order data having at least one entry, thepurchase order data including purchase order header information andpurchase order detail information; obtaining via the computer networkinvoice data having at least one entry, the invoice data includinginvoice header information and invoice detail information; comparing viaa computer selected purchase order data and corresponding selectedinvoice data to identify a matched record having purchase order data andcorresponding invoice data; creating a collaborative data set in thecentral datastore based in part on the matched record and any subsequentsettlement history; capturing post-match, settlement history by storingall additional settlement data to be used to as part of the samecollaborative data set in the central datastore, wherein at least one ofthe following is stored: credit memos, debit memos regarding the invoiceand/or the purchase order of the matched record, settlement dispute datafrom the selling company, supporting images and documentation from theselling company, settlement dispute data from the buying company,supporting images and documentation from the buying company; users fromthe buying company and users from the selling company accessing thecollaborative data set to reconcile the transaction using the matchedrecord settlement transaction history and supporting documentationstored in the datastore.

In a still further embodiment of the present invention, a method isprovided for processing transactions. The method comprises receivinginvoice data and receipt data for a plurality of transactions andstoring the data in a system database; segmenting the invoice andreceipt data into a plurality of segments using one or more user definedsegmenting parameters, each segment including a portion of the receivedinvoice data and receipt data based upon the user defined segmentingparameters; for each of the segments, automatically matching the portionof the received invoice data and receipt data within the segmentaccording to a predefined match strategy comprising a plurality ofmatching rules; and for each invoice and receipt that are matched in theautomatic matching step, assigning a unique match identifier to theinvoice and receipt and storing the invoice and receipt along with thematch identifier in the system database.

In yet another embodiment of the present invention, a graphic userinterface is provided for transaction matching. The user interfacecomprises a screen presenting the user with: a first portion showinginvoice and purchase order match information; a second portion listinginvoice line items; a third portion listing receipt of goods line items,wherein the second portion and third portion are aligned horizontally sothat the line items will also align in a horizontal manner to facilitatecomparison. The user interface may also include a fourth portion listingdebit memos and credit memos.

A further understanding of the nature and advantages of the inventionwill become apparent by reference to the remaining portions of thespecification and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of traditional prior arttransaction management system;

FIG. 2 is a schematic representation of an example transactionmanagement system in accordance with the present invention;

FIG. 3 is a flow diagram of the input data flow of the example system ofFIG. 2;

FIG. 4 is a flow diagram of an example charge code verification processof the example system of FIG. 2;

FIG. 5 is a flow diagram of an example matching process of the system ofFIG. 2;

FIG. 6 is a schematic representation of an example matching logicprocess of the system of FIG. 2;

FIG. 7 is a flow diagram of an example resolution process of the systemof FIG. 2;

FIG. 8 is a flow diagram of an example cash management process of thesystem of FIG. 2;

FIG. 9 is a schematic representation of an example supplier accessprocess of the system of FIG. 2;

FIG. 10 is a block diagram of an example distributed transactionmanagement system;

FIG. 11 is a flow diagram of an example transaction matching process inwhich invoices and receipts are segmented into a hierarchy of poolsprior to automated and manual matching;

FIG. 12 is a flow diagram of an example automated matching processproviding N-dimensional matching of invoices and receipts;

FIG. 13 is a flow diagram of an example manual reconciliation processproviding numerous matching tools for matching invoices and receipts;

FIG. 14 is a line match screen interface operable by a user of thesystem in order to manually reconcile invoices and receipts at the linelevel;

FIG. 15A is a view match screen interface operable by a user of thesystem in order to view the details of a matching process executed bythe system;

FIG. 15B is a view match notes screen interface operable by a user ofthe system in order to identify and view notes associated with aparticular match;

FIG. 16 is a notes interface screen operable by a user of the system inorder to apply a textual note to a particular transaction document;

FIG. 17 is a reconciliation queue interface screen operable by a user ofthe system in order to begin the manual reconciliation process describedin FIG. 13;

FIG. 18 is a header match screen interface operable by a user of thesystem in order to manually reconcile invoices and receipts at theheader level;

FIG. 19 is an exemplary process flow diagram for researching aparticular match and viewing the match using the view match screeninterface;

FIG. 20 is a document research queue interface screen;

FIG. 21 is a view document screen interface; and

FIG. 22 is another example view match screen interface.

FIG. 23 is a block diagram showing the creation of an new data setaccording to the present invention.

FIG. 24 is a block diagram showing the invoice statuses.

FIG. 25 is a block diagram showing the line level coding and handling ofdiscrepancies and claims.

FIG. 26 is a block diagram showing the comparison of charges andallowances according to the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the invention, as claimed. It may be notedthat, as used in the specification and the appended claims, the singularforms “a”, “an” and “the” include plural referents unless the contextclearly dictates otherwise. Thus, for example, reference to “a material”may include mixtures of materials, reference to “a bar code” may includemultiple bar codes, and the like. References cited herein are herebyincorporated by reference in their entirety, except to the extent thatthey conflict with teachings explicitly set forth in this specification.

In this specification and in the claims which follow, reference will bemade to a number of terms which shall be defined to have the followingmeanings:

“Optional” or “optionally” means that the subsequently describedcircumstance may or may not occur, so that the description includesinstances where the circumstance occurs and instances where it does not.For example, if a device optionally contains a feature for having acassette loader, this means that the cassette loader feature may or maynot be present, and, thus, the description includes structures wherein adevice possesses the cassette loader feature and structures wherein thecassette loader feature is not present.

A “server” in a hardware configuration may be a computer such as apersonal computer (PC) or other intelligent device. A server typicallyperforms the bulk of the centralized or generalized tasks in the networkand often has more memory, processing speed, and storage than the otherdevice on the client-server network. Alternatively, the server mayperform specialized tasks such as but not limited to, distributingelectronic mail, data storage or printing. In the software arrangement,a “server” typically is a program that provides data, stores data, orprovides some service to other programs to lo which the server isconnected. A server may be a program with higher priority, greatermemory, or greater capabilities compared to the other programs connectedthrough the network. A server also may be a program that includesspecialized capabilities or has higher priority with respect to certaintasks or functions.

A “client” in the software arrangement is generally a program used by auser. A client program typically makes use of data, processing, storage,or other resources of another program. A client may be used tocommunicate with a source or destination through a higher priority, morepowerful, more capable or different program. The client may run on acomputer such as but not limited to, a personal computer (PC),intelligent device, personal digital assistant (PDA) or workstation usedby a user. In use, the client may carryout tasks in the process of whichthe client may request information or otherwise may use the resources ofanother object such as the server or another client to accomplish suchtasks.

FIG. 1 schematically illustrates the traditional prior art approach tomanagement of financial and accounting transactions between tradingpartners, including buying companies 11 and selling companies 13. It isto be understood that buying companies 11 and selling companies 13include individuals, sole proprietorships, partnerships, limitedliability companies, corporations, and any other business ornon-business entities engaged in the buying and selling of products thatmay be included in purchase orders and/or invoices. Further, the term“products” includes raw materials, finished products, services, and/orany other item that may be included in purchase orders, invoices, orother billing arrangements.

FIG. 1 shows that individual buying companies 11 and selling companies13 internally manage the financial and accounting data related to theirtrading partners. This leads to inefficiencies and other difficulties asdescribed above. FIG. 2 presents a schematic representation of anexample transaction management system in accordance with the presentinvention in which a single interactive platform 15 is provided for bothbuying companies 11 and selling companies 13 to utilize as a singletransaction point to manage financial and accounting transactions withtheir trading partners. Platform 15 may be operated by a third party andmay be accessible by all parties via a computer network. Preferably,this computer network is a global computer network, and most preferablythe computer network is the internet.

Both buying companies 11 and selling companies 13 provide their purchaseorder data, receipt data, and invoice data to the interactive platform15, where the data is managed, discrepancies resolved, payments providedfor, and records kept. The trading partners complete transactions andcommunicate with each other via the interactive platform 15. Reportsrelating to transactions, financial data, and other accounting data areavailable via the interactive platform 15.

The interactive platform 15 provides a unique method and system for athird party to manage all of the accounts payable and accountsreceivable for buying companies 11 and selling companies 13. Further,interactive platform 15 may provide for centralized payment schemes, asauthorized by buying companies 11, and can conduct all of the accountpayable operations currently processed within the buying company 11.Likewise, the interactive platform 15 can conduct all of the accountreceivable operations currently processed within the selling company 13.The interactive platform 15 conducts these accounts receivable andaccounts payable operations utilizing identical data from a singledatabase.

Interactive platform 15 may also provide for management of transactionsbetween buying companies 11 or selling companies 13 with a tradingpartner that does not provide corresponding accounting information tothe interactive platform 15. For example, if a buying company 11purchases goods from a trading partner that does not provide invoicedata to the interactive platform 15, the input of purchase orderinformation, receipt information, and invoice information may stilloccur via the buying company 11, and the buying company 11 will stillenjoy the advantages of using the interactive platform 15. Also, thebuying company 11 may direct the selling company 13 to send all invoicesto the interactive platform 15 as part of the billing arrangements withthat selling company 13. However, the trading partner that does notprovide information to the interactive platform 15 may not have accessto the data in the interactive platform 15 or the advantages of its use.

The interactive platform 15 is not limited to traditional goods-orientedtransactions, but is also applicable to exchanges of services, routinepayments, or any other payable or receiving function traditionallyperformed by an accounting department. For example, the interactiveplatform 15 may be utilized to provide for payment of regular utilitybills. A rule or other operating parameter may be established for abuying company 11 that an electric bill within a predetermined range isauthorized for payment. The selling company 13, which happens to be anelectric utility, then provides the payment due information to theinteractive platform 15, and payment is automatically provided for ifthe amount is within the authorized predetermined range. Any amountsoutside the predetermined range would trigger a resolution processsimilar to that described below in relation to FIG. 7.

The buying company 11 may access the interactive platform 15 at any timefor reports regarding the payments of electric utility bills to thatselling company 13, and the selling company 13 may access theinteractive platform 15 at any time for reports regarding the paymentsmade to it by that buying company 11 or any other buying company 11. Ofcourse, that buying company 11 would not have access to reports ofinformation regarding payment to that selling company 13 by any otherbuying company 11. In such a way, a buying company 11 may automate allroutine payment processes and increase accounting efficiency.

Other examples of the utilization of the interactive platform 15 includeselling companies 13 that are insurance companies and buying companies11 that are the insured companies. Procedures similar to those describedabove could be implemented to automate provisions for insurance.

FIG. 3 is a flow diagram of the input data flow of the example system ofFIG. 2. Accounting data for the method of the present invention may beobtained in either paper format, such as paper purchase orders 12, paperinvoices 14, or paper receiving document 16, or in electronic format,such as electronic data interface (“EDI”)/Web purchase orders 18,EDI/Web invoices 20, or EDI/Web receiving documents 22. These documentsmay be received via the World Wide Web over the Internet or through anEDI system.

The paper documents 12, 14, and 16 may be received via paper deliveryservice (e.g., U.S. mail) or via facsimile transmission, etc. The nextstep is to determine whether the paper is received via mail or facsimiletransmission, as indicated by step 24. If the paper documents arereceived via fax, then the images will be sent to a fax pool 26, andinto a staging image database 28.

If the paper documents 12, 14, and 16 are received via paper deliveryservice, then the documents are scanned in step 30, using conventionalscanning techniques. After the paper documents 12, 14, and 16 arescanned, the images resulting from the scan are provided to the stagingimage database 28. With paper documents 12, 14, and 16 that are receivedvia paper delivery service, the hard paper copies are placed in storage32. The paper may be stored for any amount of time, preferably 90 days.

Once the images of the paper documents 12, 14, and 16 are stored in thestaging image database 28, they are then provided to the data entry step34 in which the images are translated into an electronic format that issuitable for further processing.

Once the data has been entered into the system through step 34, the datais evaluated and validated in step 36 to identify data that may bemissing, incorrectly input, etc. If the data validation step 36identifies any problems, then the document is provided to the dataadjudication center 38 for resolution of any problems. The dataadjudication center 38 may provide for contact with the provider of theinformation for correction of that information. Such contact may beconducted as part of the workflow resolution 60 process described inFIG. 7, or may be separate from that process.

The electronic data 18, 20, and 22 also undergoes the data validationstep 36 and is provided to the data adjudication center 38 forresolution of any problems with that data.

Once the documents have passed the data validation step 36, the imagesof the documents will be stored in the image database 40. Specific datafrom the images will be loaded into the header tables 42 and/or thedetail tables 44.

For purchase order documents 12, 18, header table 42 data may include apurchase order number, a client number or other identification, a vendornumber or other identification, a buyer number or other identification,a purchase order date, and/or an order date. For invoice documents 14,20, header table 42 data may include an invoice number, a purchase ordernumber, a client number or other identification, a vendor number orother identification, a buyer number or other identification, an invoicedate, and/or an order date. The invoice documents 14, 20 also have aninvoice total cost, which is the total cost or price of the product(s)shipped to the buying company 11 from the selling company 13.

For purchase order documents 12, 18, detail table 44 data may includethe purchase order header information and detailed entry information byline of the purchase order including an item number or otheridentification, a quantity ordered of that item, a cost per item unit,an extended price for that item, a charge code for that item, and aquantity received for that item. For invoice documents 14, 20 detailtable 44 data may include the invoice header information and detailedentry information for each line of the invoice, including an item numberor other identification, a quantity of the item shipped, a unit cost orprice for the item, and an extended cost or price for the item.Likewise, if freight charges, insurance charges, etc., are included asseparate items, then these could also be included as separate lineitems.

Receiving documents 16, 22 provide receipt data corresponding to theproduct(s) actually received by the buying company 11, on anitem-by-item basis. This information is provided by the buying company11 and is combined with information from the purchase order to determinethe total cost of goods received, which is the cost or price of theproduct(s) ordered that were actually received by the buying company 11.The total cost of goods received may be included in the purchase orderheader information 42 a. The quantity of items received and the cost ofindividual items received may be included in the purchase order detailinformation 44 a.

The data from the header tables 42 is provided to begin the exemplarymatching flow process described in FIG. 5. The data from the detailtables 44 undergoes general ledger (“GL”) charge code verification, inwhich the detailed codes set forth in the data of the detail tables 44,generally obtained from the purchase order, are compared topredetermined GL charge codes provided by the originator of the data.

FIG. 4 is a flow diagram of an example charge code verification processof the example system of FIG. 2. The data from the detail tables 44 arelating to purchase order 12, 18 information is compared to chargecodes 46 that are provided by the originator of the purchase orders 12,18. The comparison of the charge codes from the purchase order detailtable 44 a and the charge codes 46 occur on a line-by-line basis toensure that the codes contained in the detail table 44 a are validcodes. This step occurs as charge Code verification step 48. If thecodes from the detail table 44 a match the charge codes 46, then theupdate of the codes is ended at step 50. If the charge code verificationstep 48 indicates that the charge code from the detail table 44 a doesnot have a corresponding authorized code from charge codes 46, thensuspense charge codes will be assigned to the items corresponding to thenon-matching charge codes in step 52. A suspense charge code is anaccounting placekeeper pending resolution of the correct charge code.The suspense charge code and the original charge code will then beassociated with that particular item on the particular line in question.

Then step 54 queries the detail table 44 a to determine if there was abuyer associated with the purchase order. If there is a buyeridentified, then the buyer workflow resolution will be initiated in step60 b. In this step, the individual buyer associated with the purchaseorder in question is contacted (through the internet, web site, etc.) toresolve the discrepancies between the authorized charge codes from thecharge code database 46 and the charge codes from the detail tables 44a.

If there is no buyer identified in the data from the detail tables 44 a,then it is determined whether there is a default buyer for the vendoridentified on the purchase order in step 58. This is determined bycomparing the vendor from the data in the detail tables 44 a with apredetermined list (not shown) of default buyers for vendors obtainedfrom the originator of the purchase order 12, 18.

If there is a default buyer for the vendor identified in step 58, thenthe buyer workflow resolution 60 b is initiated to resolve discrepancybetween the charge codes. If there is not a default buyer for the vendoridentified in step 58 and no buyer identified from the detail tables 44a in step 54, then the matter is referred to the client administrativeworkflow resolution 60 a, discussed in greater detail below.

FIG. 5 is a flow diagram of an example matching process of the system ofFIG. 2. Purchase order header information 42 a is obtained from theheader tables 42 and compared against invoice header information 42 bobtained from the header tables 42. Corresponding purchase orders andinvoices are selected based upon matching identified information, suchas purchase order number, client number, and vendor number. Then thetotal cost of goods received and invoice total cost are compared in step62 to determine if the total cost matches within a predeterminedtolerance level. This tolerance level may be based on a dollar amount,percentage of total cost, or other criteria. If the total costs matchwithin the tolerance, then whatever difference between the total costsare coded to a balancing account 64 and the invoice is then processed tothe payment queue 66.

Whether the total costs match or not, the costs and matching statusinformation is provided to the statistics area 70 for tracking andfurther compilation. The statistics area 70 may also be used to create adigital audit trail, in which transactions, resolutions ofdiscrepancies, and access to the system by particular individuals may betracked. If the total costs do not match, then the detail tables 44corresponding to the purchase order and invoice are checked to see ifdetailed information regarding each line item on the purchase orders orinvoices is available, as identified in step 68. Whether the total costsmatch or not, that information is provided to the statistics area 70 fortracking and further compilation. If the detail required is notavailable, then step 69 illustrates that the appropriate detail isobtained. This may be accomplished by obtaining the data from the imagedatabase 40, or accessing the data adjudication center 38 to have theappropriate data input. Whether the detailed information is availableand the method of obtaining the detailed information are supplied to thestatistics area 70.

In step 72, it is determined whether there are multiple invoices orpurchase orders having matches with header information. For example, asingle invoice may correspond to more than one purchase order, or theproducts from a single purchase order may have been shipped underdifferent invoices. If there are multiple invoices and/or purchaseorders, then the detail information regarding individual line items arecompared for matching in step 74. If there are individual line itemmatches between the purchase orders, including receipt data, and theinvoices, then those may be provided to the payment queue 66. If theline items of the associated purchase orders with receipt data andinvoices do not match, then the unmatched line items are identified forfurther processing. All of this information is also provided to thestatistics area 70.

Whether there may be multiple invoices for a particular purchase orderis a set-up rule that may be selected by the customer. If a customerdoes not choose to allow multiple invoices per purchase order and apurchase order has more than one invoice matching the headerinformation, this matter is forwarded to the workflow resolution process60. If a customer does accept multiple invoices per purchase order, andthe line item match 74 indicates that there is not a match for aparticular purchase order line item because the corresponding invoice(s)has a lesser quantity than the purchase order or receipt data for thatline item, then the line item is split in step 71 to become two lineitems—one with the quantity that is on the invoice or that was receivedand one line item with the remainder of the quantity that can be thesubject of a different invoice or receiving document for the remainingquantity or part thereof.

If there were no multiple invoices or purchase orders, or if there weresplit line items from step 71, then the purchase orders with receiptdata and invoices are compared with predetermined selections from thecustomer regarding the rules by which to pay the invoices in step 75. Ifthere is not a preselected rule by which to pay the invoice associatedwith the purchase order or the split line items, then the line itemsfrom the detail tables 44 of the purchase order with receipt data arecompared to those from the invoice to determine if there is a match 74.If there is a line item match (e.g., the item number, quantity, extendedprice matches between the purchase order and invoice), then the lineitem may be forwarded to the payment queue 66.

For line items that do not have corresponding matches between thepurchase order with receipt data and the invoice, these issues areidentified in step 73 and may be provided to the workflow resolution 60for resolution. If the customer has allowed multiple invoices perpurchase order, then the unmatched line items may be placed on hold fora period of time pending separate invoices. This period of time may alsobe selected by the customer, and may be of any duration. Preferably,this period of time does not extend past 30 days, beyond which thecustomer may be contacted through the workflow resolution 60. There mayalso be a provision for items that have been placed on back-orderstatus, such that a separate period of time is specified before theissue is provided to the workflow resolution 60.

Data regarding line item matches and discrepancies are also provided tothe statistics area 70. Once the issue is resolved through workflowresolution 60, step 76 queries whether the invoice or associated lineitem has been paid. If the invoice or associated line item has not beenpaid, then the information is provided to the payment queue 66. If theinvoice has been paid, then a credit or a debit memo is generated instep 80 and provided to the payment queue 66.

If the invoice or line item is to be paid according to a rule, asidentified in step 75, then the rule is applied to the matches in step78 and the results are provided to the payment queue 66. One such rulethat may be used is the “pay lower of the two rule.” This is a set ofrules that evaluates the invoice line item and the purchase order lineitem and compares extended price. This rule allows for the lower pricebetween the two items to be paid for the quantity of items received, orthe lowest quantity of the two line items is selected and an extendedprice is calculated based upon a predetermined formula. It will bereadily apparent to one of ordinary skill in the art that there are manyrules-based alternatives for resolving how an invoice or line items uponan invoice should be paid. A rules-based payment scheme may also beapplied with multiple invoices and purchase orders.

The information from the payment queue 66 is provided to an accountspayable database 82, from which the payment process 84 is initiated.Differences between the amount invoiced and the amount paid are providedto the balancing account 64. The payment process 84 may be entirelycontrolled and contained by the originator of the purchase orders andoutside the system of FIG. 2.

The information from the accounts payable database 82 may also be usedin the process of factoring, described above, to create an improvedprocess termed “approval factoring.” Factoring, which is the selling ofthe receivable asset associated with amounts due to the selling company,is done at the time of the match (or approval for payment, discussedbelow) between the purchase order and receiving information or data withthe invoice information or data, instead of the traditional method ofselling the receivable at the time of invoice. This allows the factoringto occur based on a matched amount due. By factoring at the time ofmatch or approval, the risk to the third party associated with thereceivable asset is minimized, because the matching or approval forpayment has already occurred and any discrepancies have already beenresolved, or at least identified.

Because of this reduced risk, the discount from the face value of thereceivable may be reduced and the selling company will pay less of a feeto better manage its cash flow by receiving the cash flow at known dateswith minimal delay. Further, the factored amount may be based on theamount actually scheduled to be paid, instead of the invoice amount, andallows for factoring over multiple invoices having only partial matches.Thus, factoring may be done for individual line items from severalinvoices, instead of for an entire invoice, as is traditionally done.The third party may be the party implementing the transaction processingsystem or may be one or more other parties, such as a bank or otherreceivables factoring party.

FIG. 6 is a schematic representation of an example matching logicprocess of the system of FIG. 2. Initially, the information frompurchase order header table 42 a and invoice header table 42 b arecompared to see if there is a high level match 86 between thisinformation. Typically, the header information compared is the purchaseinvoice number, the total cost of goods received, the total cost ofproducts shipped, the client number or other identification, and thevendor number or other identification.

When comparing the information from purchase order header table 42 a andinvoice header table 42 b, the tolerances from tolerance considerationtable 88 are to be factored in. The data in tolerance considerationtable 88 is predetermined data and may be different depending upon theclient or vendor. This data may be modified.

If there is a match of the header information within the tolerance, thenpayment data is generated in step 90. The payment data is generated byaccessing or retrieving the purchase order detail table 44 a informationfor the corresponding purchase order header table 42 a information. Thenthis information is provided to the payment queue 66, the accountspayable database 82, and on to the payment process 84. Data may beprovided to the balancing account 64, for example, if there are minordiscrepancies between the total cost of goods received and the invoicetotal cost.

If the purchase order header table 42 a information and the invoiceheader table 42 b information do not match in the high level match 86step, particularly relating to the comparison of the total cost of goodsreceived and the invoice total cost, then the line item match step 74occurs comparing the purchase order detail table 44 a information withthe invoice detail table 44 b information. As illustrated, thisinformation may include purchase order number, client number, vendornumber, by line quantities (shipped and received), by line item numbers,and by line cost per unit.

If individual line items match, or if a rules-based scheme is employedto resolve differences between line items, then resolution step 92 willprovide the information to the payment queue 66. If there is no matchand no rules-based scheme to resolve the discrepancies, then the matteris referred to the workflow resolution 60, as illustrated in FIG. 7.Once the issue is resolved, then a determination is made whether theinvoice has been paid in step 76. If the invoice has not been paid, thenthe information is provided to the payment queue 66. If the invoice hasbeen paid, then a credit or debit memo is generated in step 80 andprovided to the accounts payable database 82.

FIG. 7 is a flow diagram of an example resolution process of the systemof FIG. 2. This process is utilized to resolve any discrepanciesidentified during the previous processes. If there are issues from thecharge code verification process illustrated in FIG. 4 that requireadministrative workflow resolution 60 a or buyer workflow resolution 60b, collectively referred to as charge code issues 56, or if there areissues from the matching flow process illustrated in FIG. 5 andidentified at step 73, then those issues are identified to the client byemail notification 94, for example. The email notification 94 mayinclude statistical information on the status of the charge code issues56 or matching issues 73 and may identify the role 96 of the issues aseither administrative issues 60 a or buyer issues 60 b. If the issue isan administrative issue, the email notification 94 may direct the clientto the administrative homepage 98 on the World Wide Web 100, forexample. Other networks, such as a Local Area Network (LAN) or a WideArea Network (WAN), or any other computer network may be used to accessthe administrative homepage 98. Further, the administrative homepage 98may be of any format suitable for performing the functions describedherein.

Two of the screens available for access from the administrative homepage98 are the administrative charge code resolution screen 102 and theadministrative matching resolution screen 104. Through theadministrative charge code resolution screen 102, any of the charge codeissues 56 that have been identified may be resolved. Through theadministrative matching resolution screen 104, any of the matchingissues 73 may be resolved.

If the email notification 94 identifies that the issues to be resolvedare associated with a particular buyer, then the email notification 94may direct the client to a buyer homepage 106, accessible via the WorldWide Web 100. As with the administrative homepage 98, the buyer homepage106 may be accessed through any of a variety of computer networks. Twoof the screens available from buyer homepage 106 include the buyercharge code resolution screen 108 and the buyer matching resolutionscreen 110. Through the buyer charge code resolution screen 108, chargecode issues 56 associated with that buyer may be resolved. Likewise,through the buyer matching resolution screen 110, matching issues 73associated with that buyer may be resolved. There may be many differentbuyer homepages 106, depending upon the number of buyers associated withthat particular client. Each of the buyer charge code resolution screens108 and buyer matching resolution screens 110 may also be accessed fromthe administrative homepage 98 for that client, if such authorization isdesired by the client.

Once the charge code issues 56 have been resolved through either theadministrative charge code resolution screen 102 or the buyer chargecode resolution screen 108, the next step, identified as 112 on FIG. 7,is to determine if payment has been made for the particular item forwhich there was a charge code issue 56. If payment has been made, thenthe records associated with the charge code issue are updated in step114. If the payment has not been made, however, then the recordsassociated with the charge code issue 56 are amended and the properdetail table 42, 44 is amended in step 116. After the records have beenupdated or amended, the data is provided to an audit file 118 todocument the update of the codes in the records. The information is thenpassed to the payment queue 66 and subsequently to the accounts payabledatabase 82.

Once the matching issues 73 have been resolved via the administrativematching resolution screen 104 or the buyer matching resolution screen110, then the next step is to determine whether payment has been made instep 112. Concurrently, remittance file 120 is updated with informationsuch as the buyer who resolved the issue, the date, the changes thathave been made, etc. If payment has been made, then a credit/debit memo80 is generated and forwarded to the payment queue 66 that then loadsthe information to the accounts payable database 82. If payment has notbeen made, then the audit file 118 is updated documenting the changesand updates that have been made. The record is then forwarded to thepayment queue 66 and on to the accounts payable database 82.

The system and method of the present invention may also provide fortracking of the history of the workflow resolution process, includingwho accessed or participated in the resolution, the dates and times suchaccess occurred, and the messages exchanged or provided to the system.This may be advantageous in the event that disagreements arise over theresolution, future similar discrepancies are identified, or theindividuals involved need to be contacted. This information may betracked in the statistics area 70, by a separate database, by the website software associated with the administrative homepage 98, the buyerhomepages 106, or the supplier homepage 144, or may be tracked in anyother suitable manner.

FIG. 8 is a flow diagram of an example cash management process of thesystem of FIG. 2. At a predetermined time, for example, two days priorto payment of an invoice, or part thereof, corresponding to a record inthe accounts payable database system 82, an appropriate notification isprovided to the client alerting the client that the payment is due. Sucha notification may be via e-mail as in step 122, and may be to theaccounts payable manager of the client. The primary purpose of thenotification is to alert that a payment is due within the predeterminedamount of time.

The accounts payable manager can then access the system, such as throughthe World Wide Web 100, and access the accounts payable manager moduleor homepage 124. Within the accounts payable manager module or homepage124, the manager would be able to look at the individual records forwhich notification has been sent and decide whether the payment date inthe records should be modified, as identified in step 126. If thepayment date is to be modified, then the payment is rescheduled in step128 and the item returned to the accounts payable database system 82.

If the payment date is not to be modified, then a notification is sentto the manager of the cash that will be made available for payment. Thismay take the form of an e-mail notification, as noted in step 130. Thenotification will request transfer of full funds necessary for theparticular payment. The funds are then transferred in step 132 to anaccount from which the payment will be made. Then a check in step 134will be made to verify that sufficient funds are available in theaccount to make the appropriate payments. If there are not appropriatefunds in the account, then payment is not made and the client iscontacted in step 136 to resolve the discrepancy. If there aresufficient funds, then payments are disbursed in step 138 and anyappropriate fee is also withheld in step 140.

FIG. 9 is a schematic representation of an example supplier accessprocess of the system of FIG. 2. The accounts receivable or salespersonnel 142 from the supplier will access the interactive platformthrough a supplier homepage 144. In a preferred embodiment, the accesswill be via the World Wide Web 100, but any suitable network may be usedfor access, including LAN, WAN, or other networks. From the supplierhomepage 144, the supplier personnel may access information regardingPayment research 146, cash flow 148, or adjudication 150.

From the payment research access 146, the personnel 142 may enter asearch term, such as a purchase order number or invoice number, toidentify a record corresponding to the particular data input. From therethey may see payment detail information, including whether payment hasbeen authorized, when payment was sent, etc. This is illustrated on FIG.9 by step 152.

From the cash flow access 148, the personnel 142 may see what dailypayments 154 have been made or are to be made to the supplier and maysee further remittance information 156 regarding the cash flow to thesupplier.

From the adjudication access 150, the supplier personnel 142 may see allof the adjudication items 158 relating to that supplier, including theparticular issue and the detailed information for both the purchaseorder side and the invoice side. The supplier personnel 142 may have theability to resolve the issue, but the ability is preferably limited tochoosing only a lower quantity or a lower price for the item inadjudication. For example, if the reason for an item being inadjudication is because the line item unit price has a discrepancy offive cents per item, the supplier may elect to not hold up the paymentmerely because of such a minor discrepancy. A higher quantity or ahigher price may not be chosen by the supplier at this point. If theitem is adjudicated by the supplier through the adjudication access 150,then this is removed from the client resolution workflow illustrated inFIG. 7, and immediately sent to the payment queue 66 for payment.

From the supplier homepage 144, the information supplied comes from theaccounts payable database 82 and/or the document image database 40. Atany time, the supplier personnel 142 may review the image of the invoiceor of any receiving documents that have been entered into the documentimage database 40. The supplier access and supplier homepage 144 may beof any format and is customizable to meet the needs of the supplier.

FIG. 10 is a block diagram of an example distributed transactionmanagement system 180. The system 180 is distributed in the sense thatthe system software components are not located in one system, butinstead are distributed among a variety of systems. Preferably, thesystem includes a central data center trading engine 182, or hub, and aplurality of trading modules and adapters that link a plurality ofcustomer sites (spokes) 184, 186, 188, 190 to the central data centertrading engine 182. Two different types of customer installations areshown in FIG. 10, an enterprise installation and a hosted installation.In the enterprise installation, such as the enterprise buyerinstallation 186 or the enterprise seller installation 188, the system'scollaborative back office (CBO) software (described in more detailbelow) is located at the same location as the buyer (or seller's)enterprise system. In the hosted installation, such as the buyer hostedinstallation 184 or the seller hosted installation 190, the CBO softwareis hosted by an application service provider, for example, and islocated at a different location from the buyer (or seller's) enterprisesystem. In the enterprise model, the CBO software (and all other modulesand adapters) are located behind the corporate firewall that controlsnetwork connectivity between the enterprise system and the data center182. By distinction, in the hosted installation, the CBO software andseveral other modules are not located behind the corporate firewall.Regardless of the installation approach, the central data center 182 ispreferably coupled to the buyer and seller systems via a wide areanetwork, such as the Internet. Other network connections are alsopossible, such as virtual private networks, etc.

The trading modules and adapters include a trade integration module 192,a customer adapter module 194 and a system adapter module 196 located ateach customer site. In the enterprise installation, 184, 188, all ofthese modules are located at the same location as the CBO software andthe buyer (or seller) enterprise systems. In the hosted installation,the trade integration module 192 and the customer adapter 194 arelocated at an ASP site, and the system adapter 196 is located at thesite of the customer's enterprise system.

The collaborative back office (CBO) software is provided in both a buyerversion and a seller version. Certain functionality provided by thebuyer system is preferably not provided in the seller system, althoughin alternative embodiments these software systems could be identical.For the buyer CBO software, the following functions are preferablyprovided: sorting and matching trade data; automatic and manual matchingof trade data; data reconciliation; online collaboration withsupplier(s) to speed up dispute resolution, data viewing and editing;etc. These functions are further described below with reference to FIGS.11-22, which describe an exemplary process for automated and manualmatching and reconciliation of trade data and a corresponding interfacefor use by both buyers and sellers for viewing, resolving andcollaborating on trade matters.

The seller CBO software module (as shown in 188 and 190) provides adifferent set of features from the buyer CBO software module.Preferably, these features include: reviewing invoice status (online)prior to payment; viewing detailed deduction notification data from abuyer system; reconciliation of invoice deductions; tools for buildingdeduction dispute forms; etc.

The CBO systems at each buyer and seller site interface with the buyer(seller) enterprise system (via the customer adapter 194 and the systemadapter 196) and the central trade engine 182 via the trade integrationmodule 192. The central trade engine 182 provides message validationbetween the systems, data conversion, routing, and reporting functionsbetween the various trading partners. Although just two buyer systems184, 186 and two seller systems 188, 190 are shown in FIG. 10, thesystem 180 is scalable to include any number of buyers and sellers, alltrading data and resolving financial matters though the CBO systems andthe central trade engine 182.

The trade integration module 192 links the central data center 182 tothe various CBO systems at the buyer and seller sites. It essentiallypulls data from the CBO system and provides data conversion and protocollayers to communicate the data to the central trade engine 182 and thenonto the appropriate trading partners. The customer adapter module 194is a piece of customer-specific code that links the CBO system (which isgeneric to all sellers or buyers) to a customer specific enterprisesystem through the system adapter 196. It also, providescustomer-specific alterations and/or customization of the CBO system,such as specific business rules, workflow or validation procedures thatmay be unique to the particular customer. The system adapter 196 linksto the customer's enterprise system and provides data conversion fromthe enterprise system format to the format expected by the CBO system,which is preferably in XML format.

Because the systems shown in FIG. 10 may be connected via publicnetworks, such as the Internet, system security is an importantconsideration. In addition to firewall protection, it is preferably thatdata exchanges in this system are done using public/private keyencryption techniques, and also using secure HTTPS/SFTP connections forweb-related transmissions and file transfer between servers. Forexample, when transferring a batch of transaction data from anenterprise server to the CBO software system, a public/private keyapproach is preferred. User authentication is also provided for eachuser of the system to prevent unauthorized access to the system and/orthe underlying transaction data. This user authentication is built upona permissions-based model that allows permissions, roles and groups tobe defined and configured on a per-customer basis, so that only certaindata is visible to certain authenticated users.

FIG. 11 is a flow diagram of an example transaction matching process inwhich invoices and receipts are segmented into a hierarchy of poolsprior to automated and manual matching. This transaction matchingprocess is one function of the CBO software systems shown in FIG. 10,preferably implemented at the buyer CBO systems, but alternativelyimplemented at both the buyer and seller installations.

The process begins at step 10, in which purchase order and receipt dataas well as invoice data is extracted and image processed, as describedabove with reference to FIG. 3. The extracted data is validated in step36, similar to that described above, and then stored into the system asimage data, header data and detail tables 40, 42, 44. This data can bestored at the buyer and/or seller systems 184, 186, 188, 190, or it canbe centrally archived at the data center 182 where the trade engine islocated. Alternatively, the data can be mirrored at a variety ofdifferent locations to enable both local and remote processing.Additional processes, such as those depicted in FIG. 4, above, may alsooccur at this stage of the process.

Following data extraction, validation and storage, the data is fed intoa processing queue (including stages 202, 208, 212), in which the datais sorting into logical groupings (also referred to herein as segmentsor pools) for automated and manual matching processes. In thissegmentation step 202, user defined parameters 204 are used to determinethe appropriate type of segmentation (or pooling) to perform on theextracted invoice/receipt data. These user defined parameters identifyspecific characteristics of the invoices and receipts and sort themusing these characteristics. Different pooling characteristics mayinclude: by vendor; by different combinations of a company's useridentification number, by a unique identification assigned by thecustomer's accounting department, by a specific purchase order, by thelocation where the goods were received, by department, etc. Moreover,the segmentation may be accomplished in a primary, secondary, and n-arymanner so as to develop a hierarchy of segmentation, such as initial byvendor, but then within the vendor pool, by department of the vendor,and then within the department of the vendor by location, etc., so as todevelop a tree-like hierarchy of segments to be searched by theautomated and manual matching processes 208, 212 of the processingqueue.

Using these hierarchical segmentations 206, the system is able to breakdown the matching process into smaller segments of data to be matched.This segment data is then provided to the automatic matching process 208(FIG. 12), which applies a match strategy 210 comprising a plurality ofmatching rules in an attempt to automatically match theinvoices/receipts in a given segment of data. If a match is determinedwithin the segment, then a unique match identification (Match ID) isassociated with the matched documents, and this data is then stored inthe system 206 and provided to the accounting system for payments,deductions, charge back, etc. If the data within a certain segment failsto provide a match, then alternatively a different (perhaps higherlevel) segment can be searched for the appropriate matching data, or thedata may be provided to the manual reconciliation process 212 (asfurther described below in FIG. 13-22.) By initially segmenting the data206 into these hierarchical segments (or pools), the efficiency andaccuracy of the matching process is increased.

FIG. 12 is a flow diagram of an example automated matching process 208providing N-dimensional matching of invoices and receipt data. Unique tothis process is the system's ability to iteratively compare transactionswithin a given segment of data using a set of user-defined matchingrules 210, which together provide a match strategy that can becustomized for each buyer/seller installation. These matching rules areapplied to the match data on a priority basis until a match is detected,or if no match is detected then the system can either automaticallygenerate a debit memo 242 or proceed to the manual reconciliationprocess 212.

The process begins at step 220, where the match strategy is establishedusing stored matching rules 210 that are unique to the customer. Thematch strategy is then applied to the segmented (pooled) transactiondata in order to automatically match invoices to receipt data. As notedabove, the match strategy is typically composed of a plurality ofmatching rules 210. For example, the match strategy may comprise threerules, a first rule to match one invoice to one receipt with notolerance allowed (in other words a perfect match), a second rule tomatch one invoice to one receipt if the invoice is within 10 days of thedue date with a $50 tolerance, and a third rule to match one invoice toone receipt and to pay the invoice if it is over $50. These three rulesthen comprise the example match strategy, and are applied in steps 222,224, 226, 230 and 234 to the segmented data 206.

In step 222, the system uses the matching rules 210 to determine howinvoices and receipts should be matched, such as one-to-one, all-to-allor many-to many, or any combination thereof. This type-of-matchdetermination is typically based upon past historical data and can beupdated as match results are analyzed by the system. Following thisstep, the process then applies a match level to the segmented data atstep 224. The match level determination can be done at the header level,the summary level or at the detail level. In the header level match, thesystem can make a determination (based on the header level data) to paya particular invoice or deduct the difference in a lump sum. At thesummary level, the system compares a summary invoice information andreceipt information and compute either a charge back or a line leveldeduction. And at the detail level, the system matches individual linesof the invoice/receipt.

Following the match level determination, the system then applies avariance review process 226 using variance parameters 228. The varianceparameters are defined as amount over/under, percent over/under, or acombination of the two. These parameters are then applied to the dataoutput from the preliminary matching steps 222, 224 based on thematching rules to determine if the matching data is within a particulartolerance level as defined by the variance parameters 288. Acceptance ofthe preliminary match occurs if it is within the variance parameter.

Within the variance review process 226, the system may perform a bestinvoice match and/or a best pool match. The best invoice match directsthe system directs the system to take the first invoice in the matchpool and match it to the receipt with the smallest variance within thegiven tolerance. The best pool match directs the system to calculate allpossible matches for the pool based on match level (for example, 1-1, orA - A) and match them based on the smallest variance within the giventolerance.

If the matching rules and variance steps 222, 224, 226 determine thatthere is a match, then at step 230, the process proceeds to step 232 anda unique match identifier (Match ID) is assigned to the match data. Inthis step (232), the Match ID is associated with all of the documentsthat related to the particular match, such as the invoice and receiptdocuments, and also the purchase order documents. If the resulting matchgenerates a debit memo, then the same identification number is assignedto that debit memo. This Match ID is then used to subsequently view andunderstand how the match occurred, from either the buyer or seller'ssystem, and may be used to tag additional documents that relate to thetransaction. The associated match data (along with the Match ID) is thenstored to the system database in step 238, and the match data isforwarded to the customer's accounting system for appropriate payment,etc.

If the matching rules and variance steps 222, 224, 226 determine thatthere is not a match, however, then at step 230, the process proceeds tostep 234, where a determination is made as to whether further iterationsof the matching rules (and/or variance calculations) should occur. Ifthe system determines that additional dimensions of matching areavailable, then control passes back to step 222 and the next dimension(or level) of matching from the matching rules 210 is applied to theremaining data within the analyzed segment. This process continues untila maximum iteration is achieved, which may be controlled by a userparameter 236, at which point control passes to steps 242. At step 242the system may either generate a debit memo for the unmatched (orun-reconciled) data or it may pass the data to the manual reconciliationprocess 212.

FIG. 13 is a flow diagram of an example manual reconciliation process212 providing numerous matching tools for matching invoices andreceipts. This process is typically applied to the segmented data thathas not been matched via the N-dimensional automated matching processdescribed in FIG. 12.

The manual reconciliation process begins at step 250 when a user (eitherbuyer or seller) connects to the system. This connection can occurthrough a secure web page interface, or through other types of secureconnections. Once connected to the system, the user launches 252 thereconciliation queue screen, as further described below in connectionwith FIG. 17. The reconciliation screen is the beginning point formanually reconciling invoices and receipts that failed to beautomatically matched in the N-dimensional process of FIG. 12. Thesegmented transaction data 206 is passed to the reconciliation queuescreen display 252 and provided to the user for manual reconciliation.

From the reconciliation screen (FIG. 17), several options are availableto the user for manually reconciling the transaction data, includingmatching invoices and receipts at the header level 254, matchinginvoices and receipts at the line level 256, and invoice approval 268.

Manual matching of invoices to receipts can be selected either at theheader level 254 or the line level 256. When matching at the headerlevel, the header match screen will display unapplied and appliedinvoices on the left side of the screen (See, FIG. 18), and unappliedand applied receipts on the right side of the screen. Receipts can thenbe selected or unselected with a simple button click.

When matching at the line level 256, the same side-by-side displays arepresented to the user, but the data is presented at the line level, asshown in FIG. 14 for the line match screen 270. From this screen, theuser then selects the invoice line and applies the appropriate receiptlines. Following manual matching at the line or header level 270, 276,the system then assigns the unique Match ID to the transaction documents278, stores the data (with the Match IDs tagged thereto) in the systemdatabase 280, and then forwards the match data to the buyer/selleraccounting system 282.

Semi-automated matching is provided through the quantity match 258,extended match 260 and perfect match 262 functions accessible throughthe line match screen (FIG. 14). The quantity match function 258 willapply all the receipt lines that have the same item and quantity, whichenables the system to automatically match items on the invoice andreceipt that have different unit costs. The extended match function 260determines matching invoice and receipt lines where the item and theextended costs are the same. This enables the system to handle invoiceand receipts that have different case packs (e.g., the invoice mayidentify items individually but the receipt may identify items by a boxof six or eight items). In this situation, the item count is the samebut the cost may be different because there may be different quantitiesin the case pack, however the extended match will be the same. Thus, theextended match enables the user to match items that have different casepacks. The perfect match function 262 will match invoice and receiptlines where the item number, unit price and extended costs are all thesame. Another feature that is accessible to the user is an item matchprocess, which allows the user to match only on the item number. Thisprocess enables matching of items that have the same item number butdifferent quantities and unit prices.

Regardless of which tool is selected 258, 260, 262, the system will thenassign a unique Match ID to the transaction documents 278, store thedocuments with the tagged ID value back into the system database 280,and then forward the match data to the buyer/seller accounting system282.

When any of the manual (or semi-automated) matching processes areutilized, the system may display resulting matched lines with indicatorsdescribing the quality of the match. (See, FIGS. 14, 15) Differentstatus identifiers may include: Perfect Match (PM); Overbilled (OB);Underbilled (UB) Substituted Item (SUB); or a combination of theseidentifiers, for example and underbilled substitution would have thestatus UBS as shown in the first invoice line item of FIG. 14. Inaddition, icons are displayed next to particular line item quantities toindicate how the invoice line compares to the matched receipt line. Thedisplayed icons include “̂” for over received, “v” for under received and“=” for receipt quantity equal to invoice quantity. These indicators andstatus identifiers provide additional graphical detail to the user tofacilitate proper item reconciliation.

If the user has exhausted all of the manual and semi-automated matchingfunctions, and the match still exceeds user tolerance (variance) levels,then the user can create a memo to the seller to help facilitate someother reconciliation process, and this memo is then stored into thesystem database where the seller user can access it for manualreconciliation or negotiation with the buyer user.

If the user selects the find receipts option 264, the system provides anability to find particular receipts that may not be displayed on theheader or line match screens because the receipt is either in anotherdata segment, or did not pass one of the matching rules of the matchstrategy. In step 264, the user accesses a receipts screen interface.From here, the system provides filtering and sorting options to enablefaster searching for a particular receipt. Once the receipt is found,then at step 266 the user can choose from several options, such asadding the receipt to the view match screen, altering or modifying theselected receipt, or splitting the receipt at the line level to createseveral line level receipts or line level grouping of receipts. Bysplitting the receipt at the line level, the system enables the user tomatch the same receipt to multiple invoices. This function can also beaccomplished from the line match screen 256.

Most of the functionality described with reference to FIGS. 11-22 dealswith the buyer-side reconciliation process accessed through the buyerCOB application. Within the seller COB application, the reconciliationscreens are similar to that described and shown for the buyer, in whichthe seller user can view buyer applied matches, adjustments and anysubsequent memos created by the buyer user. For example, the sellerusers can view how the buyer user matched the transaction documents, andmay then reconcile these matched documents to determine if the seller isin agreement with the buyer's match.

Another function available to the user is to convert the units ofmeasure shown on the seller invoice to the buyer's preferred units ofmeasure. This function can ease the matching process where the buyer andseller units of measure are different. Using this function, the user canconvert the invoice, invoice lines, receipt, or receipt lines in orderto facilitate the manual or semi-automated matching functions.

FIG. 14 is a line match screen interface 252 operable by a user of thesystem in order to manually reconcile invoices and receipts at the linelevel. The manual matching provided through the line match screen 252incorporates a “side-by-side” presentation style for displaying thesegmented invoices and receipts that did not pass the automated matchingprocess. Preferably, however, these invoices are for those receipts thatmet at least one of the matching rules (but not necessarily within theprogrammed variance) defined in the match strategy.

At the top of the interface is the line match display portion 304, whichdisplays a selected invoice by vendor, department number, invoicenumber, purchase order number, and location. In addition, this displayportion 304 of the interface provides financial data on the invoiceamount, allowance amount, charge amount, matching amount, receipt amountand any difference. Within the line match display portion 304, the usercan select from one of the semi-automated match functions, such as thequantity match function 258, the extended match function 260 or theperfect match function 262. In addition, the user can find a particularreceipt 264, generate a charge back item 302, or perform a matchingfunction 300 based on manually selected invoices/receipt, or lines ofselected invoices/receipts.

Below the line match display portion 304 is the side-by-sideinvoice/receipt display portions 306, 312. In the invoice displayportion 306, individual invoices lines are displayed in sequentialfashion. The invoices lines displayed include item number, status,quantity, unit cost and extended cost. The status field is describedabove with reference to FIG. 13. The quantity field includes thegraphical icon indicators 308 described above. A radio button at thefront of the invoice lines is used to select a particular invoice linefor application to a particular receipt line, either using one of thesemi-automated functions 258, 260, 262, or by manual application to aparticular receipt. The receipt lines are displayed in the receiptdisplay portion 312, and include similar information to the invoicelines. An “apply” button is positioned next to each invoice line so thatafter a user manually selects a particular invoice line, the user canmanually select a particular receipt line in order to perform the linelevel manual matching process 256.

Below the side-by-side invoice/receipt display portions is the appliedreceipt line display 310. This portion of the interface 252 showsreceipt lines that have already been applied to a particular invoiceline and provides the user with the ability to remove the application ofa particular receipt line so that it is displayed in the side-by-sidereceipt line display area 312.

FIG. 15A is a view match screen interface operable by a user of thesystem in order to view the details of a matching process executed bythe system. Along the top of the interface screen 274 is the matchsummary portion 320, which provides the details of the invoice toreceipt match performed by the system or manually by the user. Withinthe match summary portion 320 of the interface the following data isdisplayed: vendor, unique Match ID, match level, match status, matchdate, match type and the match strategy utilized in performing thematch. Also within the match summary portion 320 is a financial block330 showing the invoice amount, allowance amount, charge amount, matchamount, receipt amount, difference between the match amount and thereceipt amount, an adjustment amount and a net difference. An un-matchbutton 328 can be executed to un-do the matching performed by the systemif the user determines that there has been an error in the matchingprocess.

Below the match summary portion 320 are three sub-displays showing thedetails of the matched invoices 322, the matched receipts 324 and anydebit/credit memos that were generated 326. All of these documents aretagged with the Match ID for this match transaction and stored in thesystem database with this tag. As can be seen in these displays, asingle invoice in the amount of $69,561.90 has been matched to tworeceipts and a credit memo has been generated for the difference amount.From the view match screen, the user can return to the documentsresearch queue, as further described below in FIG. 19.

The screen shows all the information for this transaction, starting withall the invoices involved for this one particular match, all the receiptof goods included (and this could be a one to one, one to many, many toone, many to many). As an example, this may result in seven invoiceslining up to five receipts of goods. There may be one invoice andmultiple receipt of goods (one truck with 100 widgets, dropped off atthree locations). All the pieces of the transaction are included (amatch, with a chargeback, the strategy used, the type of match, creditmemo, if the process was disputed, what was the repayment, etc . . . ).The fourth quadrant of the screen (bottom left) may be reserved for theelectronic submission of chargeback.

Thus this screen shows any subsequent action related to the specificmatch (payments, repayments, deductions, calls, chats,). This preservesthe history so that if there is a post-audit, the settlement isdocumented. This screen also shows that screen, in one embodiment, maybe divided into a first portion 320, a second portion 322, and a thirdportion 324. The line items in portion 322 may align in a side-by-sidemanner so that corresponding items in portion 324 may be more easilycompared. A horizontal alignment facilitate comparisons for the humanuser. In some embodiments, it is sufficient that the portions 322 and324 are in a side-by-side horizontal configuration on the same screen.

FIG. 15B is a view match notes screen interface 332 operable by a userof the system in order to identify and view notes associated with aparticular match. This screen shows a list of notes 334 associated witha particular match. In addition to the text of the note, the date andtime of the note creation are displayed, along with an indication of thetype of note and who entered it into the system. From here the user canalso add a note 336.

FIG. 16 is a notes interface screen 272 operable by a user of the systemin order to apply a textual note to a particular transaction document.In this screen 272, a user has opened a notes window 342 and is applyinga text note to a particular invoice. This note will be associated withthe invoice and will be stored with it for future transactions. Thesystem has the ability to add these types of notes to any of thetransaction documents processed by the system. The notes can be markedsuch that only the buyer of seller can access the note, or it can bemarked collaborative, in which case both the buyer and seller can accessthe note.

FIG. 17 is a reconciliation queue interface screen 252 operable by auser of the system in order to begin the manual reconciliation processdescribed in FIG. 13. This interface includes a search box 350, in whichthe user can search for a particular invoice by vender, department,invoice number due date, PO number location, etc. The results of aparticular search are displayed in the results window 354, whichdisplays invoices due dates, PO numbers, department, location, matchamount, invoice date, etc. From here, the user can select certaininvoices for manual reconciliation as described above with reference toFIG. 13.

FIG. 18 is a header match screen interface 276 operable by a user of thesystem in order to manually reconcile invoices and receipts at theheader level. The header match screen 276 includes a match box 360 and aselection box 362. The match box displays a selected invoice by vender,department, PO number etc., and also provides additional financialdetails regarding the invoice, such as invoice amount, match amount,difference amount, etc. From the selection box 362, the user can selectcertain receipts to apply to the selected invoice. In addition, the usercan execute the find receipts function 264 if an appropriate receipt isnot displayed in the match box 362, or the user can jump to the linematch screen 256 to attempt to match the invoice at the line level.

FIG. 19 is an exemplary process flow diagram 400 for researching aparticular match and viewing the match using the view match screeninterface. The process begins from the document research queue 402,which is accessible from many of the previously discussed systeminterface screens. From the research queue, the user can either addnotes 404 or go to the view document screen 406. From the view documentscreen 406, the user can then go to the view match screen 412, as shownabove in FIG. 15A and also shown below in FIG. 22. Alternatively, theuser can begin at the receipt research screen 408, go to the viewreceipt screen 410, and then from there go to the view match screen 412.Alternatively ways of jumping to the view match screen are alsopossible.

FIG. 20 is a document research queue interface screen 402. This screenincludes a search box 420 and a search box 422. Similar to thereconciliation queue interface screen, from the document research queue,a user can enter certain search criteria and find relevant documents,which are displayed in the search results box 422. From here the usercan then select a particular document, which results in the viewdocument interface screen shown in FIG. 21.

FIG. 21 is a view document screen interface 406. This interface providesnumerous details regarding a selected document 426. From this screen theuser can select the view match button in order to display the view matchscreen details for the selected document.

FIG. 22 is another example view match screen interface as describedabove with reference to FIG. 15A.

Referring now to FIG. 23, another aspect of the present invention willnow be described. FIG. 23 shows that in one embodiment, a symbioticaccumulative process to handle trade settlement which results in thecreation of a new collaborative data set.

In one embodiment, the system according to the present invention isdesigned for access by both parties to view, reconcile, adjudicate andreport on all financial transactions between the trading partners. Alldocuments, memos, images, files, notes and correspondence related to thefinancial settlement of a transaction are captured and linked togetherin the system. This is for not only the original payment decision and/ordeduction but also all dispute requests, supporting documentation andsubsequent credits & debits-until both parties are satisfied with thefinal settlement or recognize that any additional efforts will notaffect the outcome. This information as it is brought into the system isthen shared between both parties for a single source of data for thetransaction. The creation and use of this data not only enables both thebuyer and seller to more quickly settle transactions and reduce problemsthat may typically be caught in a post audit but also allows fortransaction insight into the other trading parties business process,efficiencies, limitations, successes, etc thus creating a more accurateview of both parties efforts in the financial and physical supply chain.Both parties involved will work on one piece of data together, versusdifferent data sources being worked on separately. Any changes to anydocuments or any subsequent credit or debit memos to that process arethen saved in a collaborative data set.

FIG. 23 shows that a new data set 500 is created based settlement of atleast one invoice 502 and at least one purchase order 504 for aparticular transaction. By way of example and not limitation, the dataset 500 may be stored at a central datastore (which may be part of theplatform 15) that is accessible to users from the buying company(retailer) or the selling company (manufacturer). In the presentembodiment, a single platform 15 is used to match invoices and purchaseorders and then handle and settlement issues. Because in one embodiment,only a single platform 15 is used to process all transactions, thosetransactions can be captured to form the data set 500 related to atleast one particular transaction (whether based off of at least oneinvoice, at least one purchase order, or at least one receipt of goods).The data set 500 may contain purchaser order detail information 506 andinvoice detail information 508 obtained in this example from theretailer and manufacturer respectively. The receipt of goods information510 may also stored into the data set 500 from the retailer's receipt ofgoods . 512. This information may then be used to match invoices withpurchase orders/receipt of goods using methods as described herein. Thismay result in a retailer first settlement 516 of the transaction.

FIG. 23 further shows that embodiments of the present invention furtherincludes additional settlement information that is useful to obtain anaccurate history of the settlement transactions. As seen in FIG. 23,credit and/or debit memos 520 may also be incorporated into the data set500. This may be included as part of the detailed settlement data 522.In the present example, the manufacturer may then review settlement dataat step 524. If the manufacturer determines that the settlement wasinaccurate, they may then enter settlement dispute data 526 into thedata set 500. Supporting documentation may also be captured and scannedimages 528 incorporated as part of the data set 500. As mentioned, theretailer will have access to this same data set 500 and can see theadditional settlement data added by the manufacturer. This allows theretailer to leverage on the work done by the manufacturer and examine ifthe settlement was accurate. The retailer will review the disputed dataat step 530. The retailer may then include their own settlement disputedata 532 and images of documentation 534 into the data set 500. Theretailer may send images of pricing list, proof of Co-op advertising,etc . . .

This process of review may be iterative and as indicated by arrow 536,the process will continue until a final settlement satisfactory to bothparties is reached. The present invention allows for multiple iterationsof the resolution process (go back and forth) and all of this iscaptured by the data set 500. This is entered by the user. Each user isdoing work, but the other may benefit off of it. The data and documentsare captured and stored in same location. This is something they wouldprobably do any way, but it is being captured and stored and added tothis data set since in the present embodiment, transactions pass throughthe processing engine. Thus, all subsequent settlement transactions andsupporting documentation are captured by the data set 500 so that acomplete, cumulative trade settlement is documented. Embodiment of thepresent invention may create a collaborative data set in the centraldatastore based in part on the matched record and any subsequentsettlement history. In one embodiment, the capturing of post-match,settlement history may involve storing all additional settlement data tobe used to as part of the same collaborative data set 500 in the centraldatastore of the single platform 15, wherein at least one of thefollowing is stored: credit memos, debit memos regarding the invoiceand/or the purchase order of the matched record, settlement dispute datafrom the selling company, supporting images and documentation from theselling company, settlement dispute data from the buying company,supporting images and documentation from the buying company. Users fromthe buying company and users from the selling company accessing thecollaborative data set 500 to reconcile the transaction using thematched record settlement transaction history and supportingdocumentation stored in the datastore.

By creating a data set 500, all parties use this data set thatpreviously did not exist. Instead of individual datasets at each party'slocal computer and not being worked on by both parties, all of thisinformation is stored at one dataset accessible to both parties. Thepresent invention allows things to be stored that could not be storedbefore (and additional detail is kept). Together they build thisdatastore. This is the archival, ongoing settlement, communication, postaudit, etc . . . (the aftermath). The present invention provides bothparties with information and access they do not normally have and thisis unique to the present invention. This may include information frommanufacturer that the retailer may not normally have in anelectronically format. They cannot leverage each other's work when bothparties are not working off of the same data set. Since all parties mustwork through a single transaction platform that creates a data set foreach transaction, the settlement history is more easily tracked.

By way of example and not limitation, one party can see how the otherresolves say a price issue. Not part of any old data, this may be a newprice set based on knowledge they have gained as part of settlementiterative review by seller and buyer. For example, a bill of lading intothe system may not have been tied back to the original transaction. In apost audit, the dots are now connected. The present invention provides atrue report card of why the user was success and how the user succeeded.

It should be understood that on the retailer side, there are twoseparate processes. There is payment side and there is the procurementside (and the two are kept separate). Procurement side may write apurchase order. The delivery may have multiple purchase orders on it,but the same goods on those multiple purchase orders. Might be 10 10 and10. First purchase order may get 10, but he receives 30. Other twodeliveries may not get the goods since all thirty were delivered at thefirst stop. So, those two purchase orders are short. This highlightsthat how goods are ordered and how goods are delivered can occur in verydifferent ways. In the present invention, the same workspace is used. Acommunal workspace allows for more accurate matching and it allows forone side to connect the invoices and receipt of goods that make sense.The manufacturer may be allowed to change the matching of invoices andreceipt of goods during the iterative review. The present example allowsa user from the manufacturer to match the invoices to show that a totalof 30 units were received by retailer (even though all thirty weredelivered to one location instead of three). This rematching will thenindicate the receipt of goods does match the invoice. The totaldelivered matches the total to be paid. Not much is done in the artbeyond an initial match. The present invention archives the corrections,and this is not being tracked today.

Referring now to FIG. 24, yet another aspect of the present inventionwill now be described. Pre & post payment deduction management is shownin the figure.

In the present embodiment, the system manages multiple non-dependentstatuses for an invoice. This allows an invoice 540 to be paid before itis verified against a receipt and then have a deduction applied to itwhen it finally is matched. This enables buyers the ability to taketerms discounts even when their internal process for invoice approvalcan not be accomplished in the terms discount time frame. FIG. 24 showsthat payment status and invoice status may be decoupled. Under thepayment status, the invoice may move from being open at step 542, tobeing scheduled at step 544, and to being paid at step 546.

As seen in FIG. 24, however, this payment status may be independent ofthe invoice match status. This allows an invoice 540 to be paid beforeit is verified against a receipt and then have a deduction applied to itwhen it finally is matched. Under invoice match status, the invoice maymove from open status 550 to a matched status 552. The invoice may bemoved to a saved match status 554. Saved match is when a retail user isusing the on-line reconciliation screens and has found an invoice and areceipt that look like they go together, but still hasn't verified allof the invoice and needs to either verify it with another department,person, etc they can save the point in the match where they are so as tonot loose their work. Alternatively, the status may be an approvedstatus 556 or a deleted status 558.

Referring now to FIG. 25, it should also be understood that theembodiments of the present invention may have Carrier Claims generatedout of the line match reconciliation process. By using Line Level ReasonCodes 570, users can classify line item quantity discrepancies as acarrier claim 572, chargeback 574, or write-off 576. This functionalityincludes the ability to split an individual item discrepancy into both aCarrier Claim and Chargeback discrepancy. As the user is assigning thediscrepancies, running totals are being kept at the top of the screen toprovide a full picture of the classification process. Once theclassification process is complete, the user can perform the match andthe related chargeback and/or carrier claim will be systematicallygenerated. Both documents are tied to the original match to provide acomplete audit trail of the invoice deduction. This all in one processreduces the need for the user to have to go back post match creation andenter the necessary adjustment documents to account for the carrierclaim. In addition, the current manual process of sending the CarrierClaim packet to the logistics or transportation area can be accomplishedthrough a systematic feed through the current extract process.

Post Carrier Claim processing is also provided with allows for theAccount Rep to reverse a Carrier Claim and have the flexibility togenerate a debit memo to the merchandise vendor if necessary. Onceagain, all documents are tied to the original match to provide a fullaudit trail of the payment lifecycle.

It should be understood that embodiments of the present invention mayalso allow for add on charge and allowance matching.

Referring now to FIG. 26, at the time of an invoice match or invoiceapproval, the system compares the charges/allowances 580 on the invoiceto the Retailers internal and/or vendor defined charges/allowances 582.Vendor header level charges/allowance amounts or percents can be definedthrough the flexible Admin screens according to the present invention.For discrepancies that are not in the retailers favor, acharge/allowance chargeback is generated back to the merchandise vendor.The charge/allowance comparison is performed at both the header and linelevel. Charge/allowance chargebacks are tied to the match to provide afull audit trail of the invoice deduction. In addition, embodiments ofthe present invention provides visibility of all charge/allowance'sinvolved in the match and clearly identifies which is the “best”charge/allowance that was taken by the Retailer.

Performing the charge/allowance match prior to payment of the invoicecan reduce post audit findings. The retailer can reduce the amount ofthe vendor payment based on what they consider to be the best allowance.If the charge/allowance match was not performed, the retailer would haveto go back for the allowance discrepancy post payment.

It should be understood that embodiments of the present invention mayalso take allowance based on Goods Received. Based on the individualRetailer's business practice, the taking of allowances is not alwayssolely based on the invoice amount. For certain Retailers, the businesspractice is to only take allowances on the actual goods received. Theapplication of the present invention is flexible enough to handle bothscenarios. For allowances that are quantity based, the Retailer canchoose to apply the “best” allowance to the merchandise chargeback toreduce the amount of the deduction. Example: If the retailer onlyreceives 80% of the goods, the retailer can apply 20% of the “best”allowance to the merchandise chargeback.

While the invention has been described and illustrated with reference tocertain particular embodiments thereof, those skilled in the art willappreciate that various adaptations, changes, modifications,substitutions, deletions, or additions of procedures and protocols maybe made without departing from the spirit and scope of the invention. Itis to be understood that some operations could be carried out withdifferent elements and steps. These embodiments described herein arepresented only by way of example and are not meant to limit the scope ofthe present invention. For example, with any of the above embodiments,component pricing: (price per unit, price for shipping . . . keeping allthe individual things separate, instead of just one price) may beintroduced to provide more granularity on the price per unit. With anyof the above embodiments, every action on every transaction may betracked so that a complete history is captured. For any of the aboveembodiments, the present invention may allow for tying deductions backto original transaction (it is a different classification of documents).For any of the above embodiment, score cards and analytics may be basedon the new data set 500. Metrics may be performed on the new data set.

For any of the embodiments herein, by way of example and not limitation,the application of the present invention for settlement transactions maybe implemented within a framework of an Application Service Provider(ASP) system embedded in a central server computer platform having anetwork interface. Server platform can be a single workstation computersuch as a PC, a mainframe computer or a collection of computersinterconnected by a local or wide area network. Server platform iscapable of handling web-enabled technologies by means of web serverapplication such as BEA WebLogic Server which supports HypertextTransfer Protocol (HTTP). Such technologies include for example Javaapplets, JavaScripts, HTML, DHTML, XML, and the like on the client side,and Servlets, Java Pages (JSP) and Enterprise Java Beans (EJB) and thelike on the server side. A user of the system communicatively interfacesover a data communication network, such as the Internet or Intranet, tocentral server by conventional communication devices such as a modem, anetwork card and the like, using a software application, i.e., WebBrowser (e.g., Microsoft Explorer, Netscape Navigator).

This application is related to co-pending U.S. application Ser. No.09/777,168 (Attorney Docket No. 40877-1002) and U.S. ProvisionalApplication Ser. No. 60/533,816 (Attorney Docket No. 40877-1011) filedDec. 30, 2003. The publications discussed or cited herein are providedsolely for their disclosure prior to the filing date of the presentapplication. Nothing herein is to be construed as an admission that thepresent invention is not entitled to antedate such publication by virtueof prior invention. Further, the dates of publication provided may bedifferent from the actual publication dates which may need to beindependently confirmed. All publications mentioned herein areincorporated herein by reference to disclose and describe the structuresand/or methods in connection with which the publications are cited.

Where a range of values is provided, it is understood that eachintervening value, to the tenth of the unit of the lower limit unlessthe context clearly dictates otherwise, between the upper and lowerlimit of that range and any other stated or intervening value in thatstated range is encompassed within the invention. The upper and lowerlimits of these smaller ranges may independently be included in thesmaller ranges is also encompassed within the invention, subject to anyspecifically excluded limit in the stated range. Where the stated rangeincludes one or both of the limits, ranges excluding either both ofthose included limits are also included in the invention.

Expected variations or differences in the results are contemplated inaccordance with the objects and practices of the present invention. Itis intended, therefore, that the invention be defined by the scope ofthe claims which follow and that such claims be interpreted as broadlyas is reasonable.

1. A method of tracking transaction settlement between at least onebuying company and at least one selling company, the method comprising:providing a central datastore accessible to users from the buyingcompany and users from the selling company; obtaining via a computernetwork purchase order data having at least one entry, the purchaseorder data including purchase order header information and purchaseorder detail information; obtaining via a computer network invoice datahaving at least one entry, the invoice data including invoice headerinformation and invoice detail information; comparing via a computerselected purchase order data and corresponding selected invoice data toidentify a matched record having purchase order data and correspondinginvoice data; creating a collaborative data set in the central datastorebased in part on the matched record and any subsequent settlementhistory; capturing post-match, settlement history by storing alladditional settlement data to be used to as part of the samecollaborative data set in the central datastore, wherein at least one ofthe following is stored: credit memos, debit memos regarding the invoiceand/or the purchase order of the matched record, settlement dispute datafrom the selling company, supporting images and documentation from theselling company, supporting images and documentation from the sellingcompany, settlement dispute data from the buying company, supportingimages and documentation from the buying company; users from the buyingcompany and users from the selling company accessing the collaborativedata set to reconcile the transaction using the matched recordsettlement transaction history and supporting documentation stored inthe datastore.
 2. The method of claim 1 wherein: the transaction isreconciled using only data and documents captured and stored in thedatastore as part of the collaborative data set.
 3. The method of claim1 wherein: users from the buying company can view additional settlementdata and documents added into the collaborative data set by the sellingcompany and vice versa.
 4. The method of claim 1, wherein a singleplatform is provided for handling all transactions for trade settlement.5. The method of claim 1 wherein: users from the buying companyreviewing additional settlement data added by users from the sellingcompany; users from the selling company reviewing additional settlementdata added by users from the buying company; repeating the reviewingsteps of the buying company and selling company until a final settlementis reached.
 6. An electronic transaction processing system including acomputer network, a processing unit, and at least one data storage unit,for performing steps comprising: providing a central datastoreaccessible to users from a buying company and users from a sellingcompany; obtaining via the computer network purchase order data havingat least one entry, the purchase order data including purchase orderheader information and purchase order detail information; obtaining viathe computer network invoice data having at least one entry, the invoicedata including invoice header information and invoice detailinformation; comparing via a computer selected purchase order data andcorresponding selected invoice data to identify a matched record havingpurchase order data and corresponding invoice data; creating acollaborative data set in the central datastore based in part on thematched record and any subsequent settlement history; capturingpost-match, settlement history by storing all additional settlement datato be used to as part of the same collaborative data set in the centraldatastore, wherein at least one of the following is stored: creditmemos, debit memos regarding the invoice and/or the purchase order ofthe matched record, settlement dispute data from the selling company,supporting images and documentation from the selling company, settlementdispute data from the buying company, supporting images anddocumentation from the buying company; users from the buying company andusers from the selling company accessing the collaborative data set toreconcile the transaction using the matched record settlementtransaction history and supporting documentation stored in thedatastore.